gh-151289: optimize shrinking wide int subtraction#151290
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
1 similar comment
This comment was marked as resolved.
This comment was marked as resolved.
skirpichev
left a comment
There was a problem hiding this comment.
As I said in the issue thread, I'm not sure if this worth code complications.
Other than this, few remarks:
- Probably, you should split this pr into several. For instance, separate freelists addition looks unrelated.
- I don't think you should add benchmark script to the sources. Just include this code in pr description, for example.
sure, I'll revert and update the numbers, though I think @peendebak mentioned he had a independent freelist PR somewhere so I'll just drop mine entirely.
sure,though it's standard practices to have a |
|
Do not click the "Update branch" button without a good reason because it notifies everyone watching the PR that there are new changes, when there are not, and it uses up limited CI resources. |
|
I don't see any speedup, and in fact see a significant slowdown on the bigint path: The benchmark scripts in the original issue is not really measuring the operation I feel, so I modified it: |
|
There’s a small bug in the benchmark script in that comment: the two subtraction cases are still doing def bench_sub_compact(loops):
...
for _ in it:
a + b
def bench_sub_wide(loops):
...
for _ in it:
a + bThose should be |
|
I am not a domain expert here, so unfortunately I can't do a thorough review. 1 Footnotes
|
This specializes exact
intsubtraction for a narrow but useful case: on 30-bit-digit builds, when both operands are non-compact 2- or 3-digitPyLongobjects with the same sign and top digit, subtraction often shrinks the result. The specialized path computes that result directly instead of using generic long subtraction.This does not add a general wide-integer fast path, and compact subtraction remains on its existing path. Non-matching operands deopt/fall back to the existing implementation.
On an Ubuntu x86-64 host (GCC 15.2, 8 logical CPUs), corrected
pyperfmeasurements were:The compact, non-shrinking, and addition differences were not statistically significant in this run.
A representative eight-benchmark
pyperformancesubset showed no significant geometric-mean change.